vLLM-Ascend · 特性地图 ①分层全景 ②功能点分解 ③全表映射 ④缩写直答 ⑤与params对照 ⑥GLM 重点格 ← 返回首页
← 返回首页

vLLM-Ascend 特性地图解读:L0/L1/L2 划分 × 源码对照

vllm-ascend a71b766ce 逐项映射到代码目录 / 参数 / 教学页 2026-10-15 发布 · 对照基线 a71b766ce / bbd7c24

怎么读:vllm-ascend 的特性全景表按 L0 分为两条线——模型特性由 GLM 模型结构升级驱动、随模型走;框架特性由 vLLM 上游演进驱动、对所有模型生效。 ①全景架构图给出三层结构与两条线的职责边界;②以三个真实特性为例,对照两条线的功能链与归属判断; ③~⑥为查表区(逐格映射、缩写、params 对照、GLM 重点格)。代码落点均按 a71b766ce 核对。

① 全景架构图:L0 职责划分 → L1 特性族 → L2 具体特性项

这张图回答什么问题:特性表的三层结构、两条线的职责边界,以及 20 个特性族各自的位置。
图 1 · 特性表全景架构图(L0 / L1 / L2)
特性表全景:L0 职责划分 → L1 特性族 → L2 具体特性项
L0 · 模型特性(5 族)变更驱动:GLM 模型结构升级
验收:精度 + 单步时延 | 线:模型特性线
并行切分TP · EP · SP · PCP+DCP
细粒度切分 FinegrainedTPConfig
量化加速SFA×C8 · MoE W8A8
cache_dtype 派生 sfa_c8 / li_c8
multi stream共享专家双流 · prolog 三段流水
事件编排(record / wait ×6)
weight NZweight_nz_mode
权重转 Cube 友好 NZ 布局
融合算子MLAPO 前处理融合 · qknorm_rope
gmmswigluquant · Triton 下沉
L0 · 框架特性(15 族)变更驱动:vLLM 上游演进 | 验收:端到端吞吐 / TTFT / 显存 | 线:框架特性线
加载
权重加载多线程 · lazy
NZ 转换
调度
chunkPrefill长输入切块
块大小可调
异步调度调度/执行
两步流水
DPLB实例均衡
气泡迁移
缓存
prefixcache前缀 KV
块复用
kv offload下沉 DRAM
topk 常驻
池化层间/远端
KV 池
kv cache
管理四槽层外置
分配器
执行
CPU 侧
优化绑核
FastToken
图优化ACL Graph
静态内核
model_runner
v2新执行
底座
解码部署
投机解码mtp · dspark
dflash
拒绝采样
Samplereduce_sample
分片去重
PD 分离kv_role
mooncake
RD2H
横切
EPLB600 步热度
FlashLB 重排
L2 · 具体特性项族内按对象/子能力拆分,可独立交付;无 L2 的族为单一特性。 例:并行切分族 → DP+TP+EP+SP | 细粒度TP(LmHead / WdEb / O_proj)| PCP+DCP | PP+CPP | kv pp

各特性族职责速览

特性族职责(一句话)主要代码落点
并行切分制定切分方案,保证通信组语义与数值正确distributed/parallel_state.py、attention/context_parallel/
量化加速将 ModelSlim 量化方案在昇腾算子上实现并完成数值对齐cache_config.py、sfa_v1.py、quantization/methods/w8a8/
multi stream设计事件流水,重叠 Cube/Vector 计算空隙ops/fused_moe/shared_experts.py、attention/dsa_v1.py
weight NZ将权重转换为矩阵单元友好的 NZ 布局weight_nz_mode 消费方(权重加载 / 层初始化)
融合算子合并固定算子组合,并完成等价性验证attention/mla_v1.py、compilation/passes/、ops/triton/
阶段(框架特性)职责(一句话)主要代码落点
加载高效载入权重:多线程 / lazy / NZ 转换model_loader/
调度请求切块、调度与执行流水、DP 实例均衡core/scheduler*、patch_dyntra_lb_core.py
缓存KV 前缀复用、分层卸载、池化与块管理distributed/kv_transfer/、core/kv_cache_interface.py
执行绑核、图捕获回放、静态内核与新执行底座compilation/、worker/v2/model_runner.py
解码部署草稿解码、采样优化、PD 分离与 KV 传输spec_decode/、sample/、kv_transfer/kv_p2p/
横切MoE 专家摆放均衡(后台循环驱动)eplb/

两条线的划分依据是代码变更的驱动方:模型特性的变更由 GLM 模型结构升级驱动 (如 SFA 相关文件位于平台层,但由 GLM 稀疏注意力结构驱动,仍属模型特性线); 框架特性的变更由 vLLM 上游演进驱动(如 cache_config.py 的 C8 派生逻辑对所有模型生效, 属框架特性线)。投机解码等跨界特性按子项拆分:方法框架属框架特性线,GLM 的 MTP 头适配属模型特性线。

② 典型特性:先讲清楚是什么,再拆功能链定归属

这一节怎么读:挑三个典型特性(DP / EPLB / chunkPrefill),每个用三张图讲透:一张讲它是什么,一张看它在实测环境里的样子/效果,一张把工作链逐点拆开(蓝框★ = GLM 适配点)——蓝框★ = GLM 适配点(必须按 GLM 结构实现,换模型即失效),灰框 = GLM 无需适配的功能点(右列逐点给出原因)。链上有没有适配点,就是 L0 归属的判断依据。

特性一:DP(数据并行)——先说它是什么

DP(Data Parallelism,数据并行)就是把整套模型复制多份,每份叫一个 DP 实例,各处理各的请求:新请求到来时由负载均衡(DPLB)分给最闲的实例,实例之间互不干扰,吞吐量跟着实例数涨。实测环境 TP=16、DP=4,就是 4 份完整的 16 卡副本同时服务。注意 DP 本身不切模型、只切请求——真正要按模型结构动刀的,是每个实例内部的层内切分与通信插入(下面功能链里带 ★ 的三步)。所以「DP 归哪条线」不是一句话能答的,得拆开看每个功能点。

图 2 · DP 是什么:整套模型复制 4 份,请求分摊,吞吐 ×4
DP = 复制(不切模型)+ 分发(只切请求)
新请求队列
3500 字 prompt × 并发 8
→
DPLB
分给最闲实例
气泡超阈才迁移
→
DP 实例 0
完整模型副本(16 卡)
自己的 batch / KV Cache
DP 实例 1
完整模型副本(16 卡)
自己的 batch / KV Cache
DP 实例 2
完整模型副本(16 卡)
自己的 batch / KV Cache
DP 实例 3
完整模型副本(16 卡)
自己的 batch / KV Cache
DP 切的是「请求」不是「模型」:每份副本权重完整;实例内部 16 卡怎么协同切开一层,才是功能链里 ★ 的部分
图 3 · DP 在实测环境里的样子:TP=16 × DP=4,4 份完整副本共 64 卡
4 个实例,每个是一套完整的 TP=16
DP 实例 0
卡0
卡1
卡2
卡3
卡4
卡5
卡6
卡7
卡8
卡9
卡10
卡11
卡12
卡13
卡14
卡15
DP 实例 1
卡0
卡1
卡2
卡3
卡4
卡5
卡6
卡7
卡8
卡9
卡10
卡11
卡12
卡13
卡14
卡15
DP 实例 2
卡0
卡1
卡2
卡3
卡4
卡5
卡6
卡7
卡8
卡9
卡10
卡11
卡12
卡13
卡14
卡15
DP 实例 3
卡0
卡1
卡2
卡3
卡4
卡5
卡6
卡7
卡8
卡9
卡10
卡11
卡12
卡13
卡14
卡15
请求先到 DPLB 再进某个实例;实例之间零耦合——这正是功能点 1(请求分发)归框架线、功能点 3~5(实例内切分)归模型线的原因
图 4 · DP 的功能点分解 —— 链上有 GLM 适配点(★ 3/4/5),归模型特性线
左 = DP 推理的功能点链 右 = 各功能点归属判断(★ = GLM 适配点)
请求分发
DPLB:实例间均衡调度
patch_balance_schedule.py
1
GLM 无需适配
patch_dyntra_lb_core.py:气泡超 bubble_threshold=5.0% 才触发块级迁移;只算各实例排队块数,与模型无关
实例独立调度
各 DP rank 独立组 batch
沿用 vLLM 调度语义
2
GLM 无需适配
DP=4 即 4 个 scheduler 各自组 batch、各自管 KV pool;沿用上游 data_parallel_size 语义
★ 层内切分执行
QKV / O 投影按 tp_size 切分
细切项 O_proj_tp(FinegrainedTPConfig)
3
GLM 适配点
GLM-5.1 细切组合:lmhead_tp / embedding_tp / oproj_tp 各自设份,切法由 GLM 各层权重形状决定
★ 词表切分
LmHeadTP / WdEbTP:128k 词表
投影切分组合,仅大词表模型需要
4
GLM 适配点
128k×8192 的 lm_head 巨矩阵:词表侧与嵌入侧显存压力不同,两处切数按 GLM 词表规模单独定
★ 通信插入
SP 切片下每层插 AllGather /
ReduceScatter,插入点随切分方案变
5
GLM 适配点
例:SP 切片 TP=16,每卡 3500/16≈219 token;每层 LayerNorm 后 AllGather [1,219,8192]→[1,3504,8192],O 投影后 ReduceScatter 切回本地段
通信执行
HCCL 通信库统一执行
通信域由 parallel_state.py 管理
6
GLM 无需适配
AllGather / ReduceScatter 走 HCCL 同一实现,TP 通信域由 parallel_state.py 建组,模型不感知

结论:六个功能点中 3、4、5 三个是 GLM 适配点——它们决定 DP 在 GLM 上能否切对、跑快,更换模型即失效, 因此该特性归模型特性线。链路中的请求分发(功能点 1,DPLB)虽在同一条链上, 但为通用机制,单独归框架特性线——同一条链上两类功能点各归各线。

特性二:EPLB(专家负载均衡)——先说它是什么

MoE 模型的专家是路由制:每个 token 只去少数几个专家,于是天然不均——热门专家被挤爆、所在卡算力打满,冷门专家闲着,整卡的吞吐被最忙的一张卡拖住。EPLB(Expert Parallelism Load Balancer,专家负载均衡)干三件事:每 600 步统计一次各专家的 token 路由热度 → 按热度给过热专家复制冗余副本、重新摆放到空闲卡(专家权重 NPU 间 D2D 直接搬移)→ 对上层模型接口零改动,配置只有 eplb_config 一个入口。它只看负载统计、不看模型结构——这个特点决定了它的归属。

图 5 · EPLB 解决什么:MoE 路由不均,整卡吞吐被热门专家拖住
一批 token 路由之后:有人挤爆,有人闲死
8 个 token
各自 top-k 选专家
→
专家 0
3
空闲
专家 1
9
挤爆
专家 2
1
空闲
专家 3
5
偏忙
专家与其所在卡绑定:专家 1 打满,同卡的其他专家一起排队——整组步调被最忙的卡决定
图 6 · EPLB 怎么做:统计热度 → 复制副本重排 → D2D 搬权重,负载拉平
三步循环,对模型零改动
重摆前
卡 A:专家 0 + 专家 1
卡 B:专家 2
卡 C:专家 3
负载 4 / 9 / 5(不均)
① 每 600 步统计路由计数
② FlashLB 按热度复制副本重排
③ D2D 搬专家权重(不落 host)
重摆后
卡 A:专家 0 + 专家 2
卡 B:专家 1(主)
卡 C:专家 3 + 专家 1(副本)
负载 4 / 4 / 4(拉平)
对外只有 eplb_config 一个入口;GLM MoE 上线即被覆盖,无需任何适配
图 7 · EPLB 的功能点分解 —— 每个功能点 GLM 都无需适配,归框架特性线
左 = EPLB 运行链 右 = GLM 无需适配的原因
热度收集
eplb_updator 每 600 步统计
各专家 token 路由计数
1
GLM 无需适配
eplb_updator 每 600 步读一次各专家路由计数([num_experts] 一维向量),只读统计值
重排计算
policy_flashlb.py:以 μ+z·σ 判据
生成冗余副本重排方案
2
GLM 无需适配
policy_flashlb.py 按 μ+z·σ 定各专家冗余份数(受 max/min_replica 约束),输出「专家→卡」摆放表
权重搬移
专家权重 D2D 搬移
NPU 间直接拷贝,不落 host
3
GLM 无需适配
只搬摆放表变化的专家权重:D2D 直接拷贝不落 host,整张量按量化层布局拷贝
透明生效
对上层模型接口零改动
MoE 模型统一覆盖
4
GLM 无需适配
GLM MoE 上线即被覆盖:对外只有 eplb_config 一个入口,仓库内无 GLM 专用分支

结论:EPLB 全链路没有任何 GLM 适配点——专家均衡只看负载统计,不看模型结构, 因此归框架特性线:由框架特性线负责开发,GLM 侧只做配置与问题反馈。

特性三:chunkPrefill(长输入切块预填充)——先说它是什么

一个 3500 token 的长 prompt,如果 prefill 一口气算完,这几百毫秒里整卡都被它占住,同批的 decode 请求全部干等——长请求的 TTFT 没快,别人的 TPOT 却被拖爆。chunkPrefill(长输入切块预填充)把长输入按固定块大小切块(如 1024,由 profiling_chunk_config 配置),一次前向只算一块:块 1 算完写 KV 就让出算力,下一轮调度再算块 2,拿着块 1 的 KV 续算,注意力跨块连续。长请求被摊进多个调度轮,decode 不再被长 prompt 卡死。它处理的对象只有「请求与块」,不接触模型结构。

图 8 · chunkPrefill 解决什么:长 prompt 一口气算,decode 全被卡住
GPU 时间轴:一个 3500 token 的 prefill 占满整卡
3500 token 一次 prefill · 数百 ms 独占整卡
同批 decode 请求:★ 整段干等 → TPOT 被拉爆
batch 里只要混进 1 个长 prompt,其余所有 decode 请求跟着遭殃——这就是混部场景 TTFT/TPOT 打架的根源
图 9 · chunkPrefill 怎么做:切 4 块、分 4 轮,decode 插空
3500 = 1024 + 1024 + 1024 + 428,块间靠 KV 续算
轮 1 · 块 1
1024 token
decode
插空
轮 2 · 块 2
1024 · 携 KV 续算
decode
插空
轮 3 · 块 3
1024 · 携 KV 续算
decode
插空
轮 4 · 块 4
428
注意力跨块连续(块 N+1 拿块 N 的 KV 续算);块大小由 profiling_chunk_config 配置——GLM 侧唯一的动作就是按长文本场景调它
图 10 · chunkPrefill 的功能点分解 —— 每个功能点 GLM 都无需适配,归框架特性线
左 = chunkPrefill 功能链 右 = GLM 无需适配的原因
长请求进入调度器
例:3500 token prompt
进入 prefill 等待队列
1
GLM 无需适配
例:3500 token prompt,ids [1,3500]——调度器只见长度 3500,不感知请求属于 GLM
按块大小切块
profiling_chunk_config:
块大小为服务侧配置(如 1024 / 2048)
2
GLM 无需适配
chunk_size=1024 → 切 4 块 [1024, 1024, 1024, 428];块大小由 profiling_chunk_config 配置,不含模型信息
逐块排队执行
块作为独立调度单元
与其他请求混排,每块一次前向
3
GLM 无需适配
4 个块与其他请求统一排队;每块一次 prefill 前向,调度比较的只有块数与显存
KV 逐块累积
块 N 的 KV 写入 cache
块 N+1 携历史 KV 续算,注意力跨块连续
4
GLM 无需适配
块1 KV [1,1024,8192] 落 cache;块2 以 Q[1,1024] 对累计 KV[1,2048] 续算,读写全走统一 cache 接口
全模型透明生效
GLM 1M 长文本按同一规则切分
无模型侧改动
5
GLM 无需适配
GLM 1M 上下文按同一规则切分;GLM 侧唯一动作是按长文本场景改 profiling_chunk_config

结论:chunkPrefill 的每个功能点都只处理「请求与块」,不接触模型结构——GLM 在链上没有任何 需要按自身结构实现的内容,因此归框架特性线;GLM 侧唯一的动作是按长文本场景 调整块大小参数(profiling_chunk_config,params-01)。

③ 全表映射:每一格的代码落点与解释

下表 = 原特性表逐行保留(前三列),后四列是本次核对的映射: 是什么 / 代码落点 / 关键参数 / 教学页。标 ★ 的与已发布教学页直接对应。

3.1 L0 模型特性(五族)

L1L2是什么代码落点关键参数教学页
并行切分DP+TP+EP+SP四种基础并行维度:数据/张量/专家/序列并行vLLM parallel_config + distributed/parallel_state.pyparallel_config.*params-05
LmHeadTP + WdEbTP词表投影/词嵌入的细粒度切分(大词表模型单独选份数)ascend_config.py FinegrainedTPConfiglmhead/embedding_tensor_parallel_sizeparams-05
O_proj_tp注意力输出投影细切同上oproj_tensor_parallel_sizeparams-05
PCP + DCP预填充上下文并行 / 解码上下文并行(KV 按 sequence 维切分,PCP 切长输入、DCP 切解码历史)attention/context_parallel/(common_cp/dsa_cp/dsa_v41_cp)prefill/decode_context_parallel_size、enable_dsa_cpDCP 学习材料
PP + CPP流水线并行(按层切)+ CP×PP 组合形态(CPP 全称仓库内无定义,待确认)pipeline_parallel_sizepp—
kv ppKV 传输支持流水线(mooncake 层间池过 PP)kv_transfer/kv_p2p/mooncake/pull_worker.py——
量化加速attention + indexer★ SFA 主 KV / Lightning Indexer K 的 C8 打包量化attention/sfa_v1.py、indexer.pycache_dtype / indexer_kv_dtype(派生 sfa_c8/li_c8)params-04
moeMoE 权重/激活 W8A8 量化路径quantization/methods/w8a8/ModelSlim 量化配置—
kvcacheKV cache 量化(cache_dtype)vllm cache_config + sfa 打包cache_dtypeparams-04
multi streammoe 双流★ 共享专家双流 / DSV4 DSA prolog 双流(Vector/Cube 交替空隙填满)ops/fused_moe/shared_experts.py、attention/dsa_v1.py:1919multistream_overlap_shared_expert、multistream_dsv4_dsa_overlapparams-02
weight NZmoeMoE 权重 NZ 布局(矩阵单元原生格式)weight_nz_mode 消费方(权重加载/层初始化)weight_nz_mode—
attention注意力权重 NZ 布局
融合算子moe★ 分组矩阵乘+SwiGLU+量化融合(gmmswigluquant)quantization/methods/w8a8/w8a8_dynamic.py、ops/fused_moe/ascend_fusion_config.fusion_ops_gmmswigluquantparams-03
attention★ MLAPO 全前处理融合 + 图 pass(qknorm_rope / norm_quant)attention/mla_v1.py、compilation/passes/enable_mlapo、fuse_qknorm_rope、fuse_norm_quantparams-03
triton 优化Triton kernel 层的优化(批不变、indexer 辅助、卸载 gather 等)ops/triton/——

3.2 L0 框架特性(十五族)

L1L2是什么代码落点关键参数教学页
权重加载—多线程加载 / lazy 加载 / NZ 转换model_loader/enable_multithread_load、safetensors_load_strategy—
prefixcache—前缀缓存命中(相同前缀复用 KV)vLLM KVCacheManager + ascend patchenable_prefix_cache—
chunkPrefill—长输入切块分步预填充(Ascend 增强:实测调 chunk 大小)core/scheduler_profiling_chunk.pyprofiling_chunk_configparams-01
kv offload—★ 稀疏 KV 分层卸载(全量下沉 DRAM + topk 常驻缓冲)attention/sfa_kv_offload.py、kv_transfer/sparse_kv_offload/sparse_kv_offload_configparams-04
池化—KV Cache Pool(层间/远端池化存储,配合 PD 传输)kv_transfer/kv_pool/、attention/indexer_kpool.py——
DPLB—★ DP 实例负载均衡(数量均衡 + 块级气泡迁移)patch/platform/patch_balance_schedule.py、patch_dyntra_lb_core.pyenable_balance_scheduling、dyntra_lb_configparams-01
EPLB—★ 专家负载均衡(热度收集 → FlashLB 重排 → D2D 搬权重)eplb/(eplb_updator、policy_flashlb)eplb_configparams-05
异步调度—异步调度器(调度与执行两步流水,减少 CPU 等待)core/recompute_scheduler.py(AsyncRecomputeScheduler)—params-01 提及
cpu 侧优化FastTokenCPU 侧 token 处理加速(不在 vllm-ascend 仓库内,外部/配套库)—(外部库)——
CPU bind★ worker 进程绑核(防 OS 漂移抖动)cpu_binding.py、worker/worker.py:931enable_cpu_bindingparams-02
图优化图基础功能ACL Graph 捕获/回放基础链路compilation/compiler_interface.py、worker/worker.py—params-06
static_kernelMoE 静态内核(形状预编译)ops/fused_moe/routed_experts.py:376enable_static_kernelparams-06
supper_kernel(sic)Super Kernel(#16885;原表拼写为 supper)——与 static_kernel 是 validator 别名关系同上enable_super_kernelparams-06
fusion_pass★ 图融合 pass ×3(norm_quant / qknorm_rope / muls_add)compilation/graph_fusion_pass_manager.py、compilation/passes/fuse_norm_quant 等params-03
投机解码mtpMulti-Token Prediction 草投头(DeepSeek/GLM 自带)models/deepseek_mtp.py 等speculative_configparams-07
dspark★ 置信头 + 动态验证预算步数(无图模式)spec_decode/dspark_proposer.py、models/deepseek_v41/dspark.pydynamic_spec_config.method=dsparkparams-07
eagleEAGLE 系草稿spec_decode/eagle_proposer.py——
dflashDFlash 草稿(动态步数另一方法)spec_decode/dflash_proposer.pydynamic_spec_config.method=dflashparams-07
拒绝采样验证 kernel(块验证/熵验证 + 两旋钮)sample/rejection_sampler.pyrejection_sampler_configparams-07
kv cache 管理—★ 四槽层外置分配器 / 块管理 / KV 管理器(V4.1 的 KV+索引K+scale 同页打包)core/kv_cache_interface.py、models/deepseek_v41/cache_config.py—params-04
PD 分离PD 配比寻优P/D 实例数与配比的性能寻优部署层(kv_transfer 配置 + 基准)kv_role—
kv_connectorKV 传输连接器(mooncake / RD2H / 层间池)distributed/kv_transfer/kv_p2p/、kv_pool/kv_transfer_configparams-04
Sample—采样器(分片去重 reduce_sample 等)sample/sampler.pyenable_reduce_sampleparams-01/07
model_runner_v2—新一代模型运行器(MRV2:与 MRV1 并行的新执行底座,近期大量特性优先落 MRV2)worker/v2/model_runner.pyuse_v2_model_runner—
标 ★ 的格子是已发布教学页直接覆盖的内容(params 系列 8 篇 + DCP 学习材料), 点击教学页列可跳转。特性表与教学系列的覆盖关系:模型特性五族 ≈ params-02/03/04/05; 框架特性十五族中 DPLB/EPLB/图优化/投机解码/kv offload/kv cache 管理/chunkPrefill/Sample ≈ params-01/03/04/05/06/07。

④ 缩写直答:容易卡住的几个名字

缩写全称 / 含义(已按仓库核对)
PCPPrefill Context Parallelism——预填充侧上下文并行(切长输入);上游字段 prefill_context_parallel_size;配套 enable_pcp_o_proj_weight_sharding
DCPDecode Context Parallelism——解码侧上下文并行(切解码历史 KV);decode_context_parallel_size;vllm-ascend 实现 dsa_v41_cp.py
CPP两个仓库的并行配置里均无此字段。按上下文推断为 CP(上下文并行)叠加 PP(流水线)的组合形态——全称待确认
WdEbTPWord Embedding TP=词嵌入的张量并行切分(= embedding_tensor_parallel_size)
FastToken不在 vllm-ascend 仓库内——CPU 侧 token 处理加速的外部/配套库(与 tokenizer/detokenize 链路相关)
池化KV Cache Pool=KV 的池化存储(层间池 layerwise / 远端池 ascend_store,配合 PD 传输);distributed/kv_transfer/kv_pool/
DPLBDP Load Balancer=DP 实例负载均衡(balance 调度 + dyntra 气泡迁移)
supper_kernel原表拼写,代码里是 Super Kernel(PR #16885);与 static_kernel 是 validator 别名
MRV2Model Runner V2=新一代模型运行器(worker/v2/model_runner.py)

⑤ 与参数教学系列(8 篇)的对照

已完结的 params 系列(八类总览)正好是特性表 带参数视角的子集——特性表按"特性交付"分格,params 按"配置开关"成篇,两种视角互查:

params 篇覆盖特性表的格子
params-01 调度框架:chunkPrefill(profiling_chunk)/ DPLB / 异步调度(提及)/ Sample(reduce_sample)/ kv cache 管理(mega_moe 容量申报)
params-02 多流模型:multi stream(moe 双流);框架:cpu 侧优化(CPU bind)
params-03 算子融合模型:融合算子(moe / attention);框架:图优化(fusion_pass)
params-04 KV 与稀疏模型:量化加速(attention+indexer / kvcache);框架:kv offload / kv cache 管理 / PD 分离(kv_connector)
params-05 并行与均衡模型:并行切分(LmHeadTP/WdEbTP/O_proj_tp);框架:EPLB
params-06 图模式框架:图优化(图基础功能 / static_kernel / super_kernel;fusion_pass 见 params-03)
params-07 投机解码框架:投机解码(mtp / dspark / dflash / 拒绝采样)
params-08 精度一致性(特性表外延伸):RL 训练场景的批不变与跨框架一致

特性表里本系列还没讲的格子(后续选题):PCP+CPP(上下文并行流水线)、 kv pp、weight NZ(moe/attention)、triton 优化、权重加载、prefix cache、池化、FastToken、 PD 配比寻优、model_runner_v2。

⑥ GLM 视角:重点关注的格子

结合 GLM 系模型的结构特性(KDA 注意力 / 稀疏索引 / MLA / MoE / 1M 上下文),特性表里 与 GLM 强相关的重点格(也是精度与性能问题的高发区域):

链接与基线

华杉的技术博客 · 苏ICP备2026063680号-1
首页